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Reo, an exogenous channel-based coordination language, is a model for service coordination wherein 
services communicate through connectors formed by joining binary communication channels. In or¬ 
der to establish transactional communication among services as prescribed by connector semantics, 
distributed ports exchange “handshaking” messages signalling which parties are ready to provide or 
consume data. In this paper, we present a formal implementation model for distributed Reo with 
communication delays and outline ideas for its proof of correctness. To reason about Reo imple¬ 
mentation formally, we introduce Timed Action Constraint Automata (TACA) and explain how to 
compare TACA with existing automata-based semantics for Reo. We use TACA to describe “hand¬ 
shaking” behavior of Reo modeling primitives and argue that in any distributed circuit remote Reo 
nodes and channels exposing such behavior commit to perform transitions envisaged by the network 
semantics. 


1 Introduction 

Service-oriented systems (SOS) are composed of autonomous services deployed on remote machines and 
accessed through the network. Reo coordination language lUl is an extensible notation for compositional 
modeling and execution of SOS. Services that have no prior knowledge about each other communicate 
through channel connectors which guarantee that each participant, service or client, receives right data 
at the right time. Each channel is a binary function that imposes synchronization and data constraints 
on input and output messages. Channels can be composed to realize complex behavioral protocols, 
including multi-party synchronous rendezvous. This approach enables models that are both concise and 
compositional, but it also makes operational semantics for Reo non-trivial. 

The most basic semantic model for Reo is constraint automata (CA) @. States or locations in 
CA represent configurations of data stored in the buffers of Reo networks, while transition labels are 
composed of (i) sets of channel ends where dataflow is observed simultaneously, and (ii) data constraints 
necessary to trigger such transitions. The CA for a Reo connector can be computed as a product of the 
CA for its parts (sub-connectors or channels). CA is the theoretical basis for validation and verification 
tools for Reo, which are integrated in a framework known as the Extensible Coordination Tools (ECT^ 

The Quality of Service (QoS) of a SOS depends on the quality of its components, efficiency of the 
“glue code” that coordinates individual services, and quality of the communication network. To evaluate 
the QoS of SOS coordinated by Reo, we need to estimate time to deliver input messages supplied by 
services to the input ports of the circuit to their consumers - services listening to the output ports of 
the circuit. The early semantic models for quantitative Reo l|4j |3 assumed that delays in channels do 
not affect the operational semantics of Reo. This assumption is not realistic and limits the degree of 
concurrency in the presence of transactions with different durations. Hence, a more refined semantic 
model for Reo ifT^ was introduced to solve this problem. 

'http://reo.project.cwi.nl/ 

Javier Camara and Jose Proenca (Eds.): ^ . 

,, , T • , „ r . , , ■ r © N- Kokash 

13 th International Workshop on Foundations ot jr . .... . . . 

^ .. . T . .. .r . . ■ A....... This work IS licensed under the 

Coordination Languages and Sell-Adaptive Systems (FOCLASA 14) ^ ^ t ■ 

EPTCS 175, 2015, pp. 1-0 doi: 10.4204/EPTCS. 175.1 Creative Commons Attribution License. 


© N. Kokash 

This work is licensed under the 
Creative Commons Attribution 




2 


Handshaking Protocol for Distributed Implementation ofReo 


A ■ - B A -- B 

Sync LossySync 

A 

Filter Transform Merger Replicator 

Figure 1: Graphical representation of basic Reo channels and nodes 

Distributed Reo ports exchange technical messages signalling the readiness of coordinated services 
to provide or consume data. It has been recognized that the implementation of Reo should be distributed 
to avoid performance bottlenecks ||2T1 . The existing semantic models for Reo focus on the description 
of the observable dataflow and are not suitable for the implementation and QoS evaluation. In this paper, 
we present a formal coordination protocol that can serve as foundational basis for distributed time-aware 
Reo implementation. One of the main issues is to decide which requests are considered simultaneous 
and should synchronize on each execution cycle. In our approach, we propose to use a timeout which 
each node in a network should wait for to acquire the information about pending requests on remote ports 
and decide which transition to fire. The timeout is chosen to guarantee that the information about the 
communication requests on boundary ports is propagated through the circuit. 

The remainder of this paper is organized as follows. In Section we explain the basics of Reo. 
In Section]^ we describe a semantic model for Reo used and extended in this paper. In Section]^ we 
explain the objectives of our work. In Section]^ we present implementation semantics for basic types of 
Reo nodes and channels. In Section]^ we explore the properties of our approach. Section [^overviews 
related work. Finally, Section [^concludes the paper and outlines future work. 

2 Reo Coordination Language 

Reo is a coordination language in which components and services are coordinated exogenously by 
channel-based connectors iT]. Connectors are graphs where the edges are user-defined communica¬ 
tion channels and the nodes adhere to fixed routing rules. Channels in Reo are entities that have exactly 
two ends, also referred to as ports, which can be either source or sink ends. Source ends accept data into, 
and sink ends dispense data out of their channel. 

Although channels can be defined by users, a set of basic Reo channels (see Figure [T]) suffices to 
implement most common workflow patterns [5l|. Among these channels are (i) the Sync channel, which 
is a directed channel that accepts a data item through its source end if it can instantly dispense it through 
its sink end; (ii) the LossySync channel, which always accepts a data item through its source end and 
tries to instantly dispense it through the sink end. If this is not possible, the data item is lost; (iii) the 
SyncDrain channel, which is a channel with two source ends that accept data simultaneously and loses 
them subsequently; (iv) the AsyncDrain channel, which accepts data items only through one of its two 
source channel ends at a moment in time and loses it; and (v) the FI FO channel, which is an asynchronous 
channel with a buffer of capacity one. For data manipulation, Reo introduces the Filter channel, which 
always accepts a data item at its source end and synchronously passes or loses it depending on whether 
or not the data item matches a certain predefined pattern or data constraint, and the Transform channel, 
which applies a user-defined function to the data item at its source end and synchronously yields the 
result at its sink end. 

Channels can be joined together using nodes. A node can be a source, a sink or a mixed node. Source 
and sink nodes form the boundary nodes of a connector to enable the interaction with its environment. 


FIFO 
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Source nodes act as synchronous replicators, and sink nodes as non-deterministic mergers. A mixed 
node combines these two behaviors by atomically consuming a data item from one of its sink ends at the 
time and replicating it to all of its source ends. Often two other nodes, route and join, are used to model 
non-deterministic routing and synchronization of flow, respectively. The router can be constructed from 
basic Reo channels while the join node is a shorthand notation for a component that forms a tuple from 
data items received from several channel sink ports. 

Channels can also differ at the level of their QoS. In quantitative Reo ||4l, channels are characterized 
by a set of associated QoS parameters such as communication delays or cost. We recognize two types 
of communication delays: handshaking delay, or time to decide whether the connector can satisfy the 
I/O request on its ends, and data transfer delay, or the time needed to transfer the data accepted by the 
circuit. 


3 Semantic models for Reo 

The semantics of any Reo connector can be better understood in terms of a specific semantic model and 
its appropriate translation into that model. 

The most basic semantic model for Reo is constraint automata (CA) |(6l. Transitions in CA are 
labeled with sets of ports that fire synchronously and data constraints on these ports. For example, a CA 

dA=‘lB,{A,B} 

for the Sync channel with port ends A and B contains one state (^o) and one transition - > sq. 

The FIFO channel with ports A and B is described by a CA with two states corresponding to an empty 

d—dAj{A} dB—d,{B} 

buffer (^o) and a full buffer (^i), and transitions si and sq. The behavior of any Reo 

circuit can be computed using the product of CA of its basic channels. The hiding operator is introduced 
to abstract from unnecessary details such as dataflow on the internal ports Q. 

Timed constrained automata (TCA) l|2l represent CA with clock assignments and timing constraints. 
The semantic models for Reo have been extended to compositionally compute QoS l|4l|3l, including 
communication delays in the circuit. It was assumed that delays do not affect operational semantics of 
the circuit and QoS labels were added to the transitions of basic CA. However, an example in ifT^ shows 
that such approach limits concurrency in the circuit. Action constraint automata (ACA) were introduced 
to overcome this issue ifT^ . ACA distinguish several kinds of actions triggered on channel ports to signal 
the state changes of the channel: 

Definition 3.1 (ACA Qgl) An action constraint automaton ^ = {S,,yV ,^,so) consists of a set of states S, 
a set of action names .yV derived from a set of port names .Jf and a set of admissible action types .fA, 
a transition relation —)■ C S x 2'^ x DC x S, where DC is the set of data constraints over a finite data 
domain Data, and an initial state sq G S. 

An ACA model proposed in |[T6l uses the set of action types = {b,u}, where b stands for the 
‘block’ and u stands for the ‘unblock’ actions to model synchronous channels with data transfer delays: 
when a channel is blocked, it does not accept new I/O requests. ACA is the generalization of CA, and 
CA can be seen as ACA with one action type: data flow through a Reo node. 

To reason about the correctness of ACA as semantic models for Reo, we introduce a refinement rela¬ 
tion for ACA with various action types (in a specific case, for ACA and CA as the latter is equivalent to 
the ACA with one action: observation of dataflow on Reo ports). For simplicity we omit data constraints 
in the rest of this paper and focus on ACA synchronization constraints. First, we need to be able to 
say whether automata with various observable actions describe the same Reo circuit or not. Thus, we 
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introduce an action renaming operator to unify sets of action names, show its compositionality and then 
define a weak bisimulation relation to compare ACA with renamed actions. Proofs for the following 
properties can be found in ITTI . 

Definition 3.2 (Action renaming) For any sF = let p{r^,R) be an action renaming op¬ 

erator where R is a set of renamings in the form x ^ y, x € H JF, y = p{x), p \ H ^ H' F jF'. 
P{£/,R) = {S,^' ,so) is an ACA such that for any {s,N,s') G —there exists {s,N\H U p[N Cl 
^]Ao) • 

Proposition 3.1 (Commutativity of renaming and hiding) p{hide{£/,K),R) = hide{p{£/,R), {K \ 
H)Up[KnH]). 

For HDK = 0 it holds that p{hide{xi/,K),R) = hide{p,R),K). 

As in ifTSl . we use the port synchronization function 7 as follows: we write JF,^ for yF\yil^j 
and for yF\72l^]- Ih for subsets Ni C N2 C it holds that 7; = 72^^[A2] we write 

M 1 7A^2 = (hli n ) U 7f' [Ni ] U {N2 n ). Hence, Ai | ^ A2 is the union Ni U N2 but with the parts of Ni 
and N2 that are identified via 71 and 72 replaced by the shared names [Ai] = 72^^ [A2]. The following 
proposition states that the action renaming is compositional provided that in the product of ACA we 
rename the set of synchronized actions that is obtained from the sets of renamed actions in the original 
automaton: 

Proposition 3.2 (Compositionality of action renaming) Let £F\ = {S\,JFi, —, s^) and sF2 = {S2,cF, 
—>■^2 Aq) ACA with disjoint sets of action names, ,A\ n .JF2 = 0 . Let also 7: aF -a x .JF2 be an 

action synchronization function defined as y{n) = (71 (n),y2{n)), where 71 : ,yF —)• aFi, 72 : aF -a .AF2 is a 
set of injective functions that map action names from the new set aF into action names from the initial sets 
^ and AF2, aF C {^aF\ U^) = 0 . Given sets of renamings R\ : {v —)• y = pi (x), pi .H\ -aLi,H\ G JF\} 
and /?2 • {-T —y = P2(x), P2 : H2 ^ L2,H2 G ^},/or and XA2, respectively, and a set of renamings 
7 ? = {x — )■ y = p (x) } for their product, where 


p(x) 


pi(x) X GC//i |y//2 

< P2(x) X G 7/2 c//i |y//2 

,/(Pl(xi),P2(x2)) X= 7f^(xi) = 72 ^'(x 2 ),Xi G T/i, X 2 G 7/2 


it holds that 

P(Mc< 7^2,7?) =p(M,7?l)cxla,p(i/2,7?2)- 

Here (O : —)• x .^#2) A an action synchronization function for the renamed actions defined as 

( 0 {n) = {(0\{n),(02{n)), ft)i ■. JF ^ Jf\,o>2-. M ^ JFz, 

JF = p{Hy 1^772] U^\( 77i 1^772), 

.^1 =p[77i]U^\77i, .^2 = P[772]U^\772, 

7i(?i) =ni A72 (?i) =n2 iff (0]_{p{n)) = p{ni) AC02{p{n)) = pfiz). 

Note that hiding can be seen as renaming to unobservable action T. Hence, it is compositional under 
the same conditions. 

We define traces for ACA in a usual way: a finite or infinite sequence of transitions 

No Ni N2 

->■ i'l - > S 2 


r = s 


>53... 
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is an 5 -trace in ACA. Let S* be the set of all finite sequences over a set S. Given finite sequences ai and 
02, we denote their concatenation Oi - 02- If for some ACA there exists an 5 -trace 

A'l 0 0 A^2 0 0 

5 - 5 l -)■ 52 ->• 53 - > 54 -55 - 56 - > s', 

M-0-0W2'0W3-0 

where Ai,A2,A^3 C ^ are sets of actions representing ACA labels, we write 5- > s', 

Ni-N2-Ni 

or 5 s' for the empty action set abstracted traces. 

Definition 3.3 (Weak bisimulation) Let sA = (S, , so) be an ACA. A weak bisimulation on is 

an equivalence & on S such that for all (51,52) G 0 ifsi =^> pi then 52 =A p2 for some {p\,p2) G 0 - 

States 5 i and 52 are called weakly bisimilar iff there exists weak bisimulation Af such that (51,52) ^ 

Definition 3.4 (Action refinement) Let si = (S,sV,^^,so) and SS = {Q,^,^gs,qt)) be two ACA. 
We say that si is an action refinement of AS, written as Ad ^ si, iff there exist a set K C ^ and a set of 
renamings /? = {x —)• y = p{x), p : ■sV\K —)• ./#} such that and p(hide(si,K),R) = ,^',S(f} 

are weakly bisimilar. 

Proposition 3.3 (Compositionality of action refinement) Let si\ = and Sd\ = {Qi, 

sii\ be two ACA such that Adi ^ Ai with a set of hidden actions K\ C ,yYi and a set of renamings 

Ri : {x^y = pi{x), pi : sVi\Ki sffif. Let si2 = ( 52 , =^2,-^2/2^0) =^2 = ( 22 ,^ 2 ,->i^ 2 >‘?o 

two ACA such that AS2 ^ si2 with a set of hidden actions K2 C .Ji 2 cmd a set of renaming R2’. {x^y = 
P2{x), p2 '■ -Ail \ ■S'2 —)• ./#2}• Assume also that sVi n ^ = ./#i n .^2 = 0 - 

The y-synchronous product of automata jAi and si2 is the action refinement of the (O-synchronous 
product of automata AS\ and AS2, i.e., 


Adl tX](o ^2 A- si2 


with a set of hidden actions K = K\ \yK2 and a set of renamings /? = {x —)• y = p{x) : {sVi \Ki) \y{sf2 \ 
K2)} —)■ .yffi I CO -#2 where p (x) is defined as in Prop. 3.2 7 = (71,72), 71 : .yV —)■ yVi, 72 : aC -y J/2 and 
m = (mi,t02),wi : .JK —)• yff\, (O2 : —)• .^2 action synchronization functions such that 


^n(^U^)=0, .^C{^iCiJf2)=^,and 
yiin) =niAy2{n) =n2 iff (Oi{p{n)) = p{ni) A(02{p{n)) = p{n2). 


4 Semantic model for Reo implementation 

Existing semantic models for Reo describe the coordination behavior of Reo circuits but do not show 
how to achieve it. We refer to the process of exchanging messages among remote Reo nodes in order to 
establish whether they are ready to accept or provide data as handshaking protocol: before transmitting 
service data, Reo nodes notify each other about their internal states. It is not clear how Reo nodes and 
channels should behave to determine which transitions are enabled and agree to perform one transition 
from the set of enabled ones. Specifying such behavior is important for the generation of executable 
coordination code 1211 . 

In Reo, large synchronous regions can be constructed. By synchronous region we understand part 
of a circuit consisting of joint synchronous channels. Figure shows a synchronous Reo circuit with 
eight boundary nodes and its operational semantics in the form of ACA. In this circuit, 4 source nodes 
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may provide data, 4 sink nodes may consume data, while 7 mixed internal nodes together with channels 
coordinate data flow. Here L is an exclusive route node, M is a join node, and other nodes and channels 
behave as explained in Section Assume that a write request arrives on node A. A can accept this 
request iff (i) D has a pending write request, (ii) nodes C and G are ready to accept, and (iii) there is 
no data flow on port M (required by the semantics of the AsyncDrain channel). If nodes are deployed 
on remote machines, the node cannot decide whether to accept data until it receives messages from all 
parties it depends on. If several transitions are enabled (as shown by the ACA semantics, 11 transitions 
are possible in our example if all boundary nodes are ready to communicate), the implementation should 
non-deterministically choose one of them. 

The goal of the handshaking protocol is to ensure that the internal choice made by Reo nodes locally 
lead to the correct implementation of the global observable behavior of the circuit. For example, if 
there are pending requests on nodes K, O and S, but no request on node N, the exclusive router L 
should transfer data to the node P and the merge node R should consume data from node P because 
transition {K,L, 0 ,P,R,S} (corresponds to an observable transition {/f, 0 ,P}) is enabled and should not 
be excluded by a local choice of a node or a channel with non-deterministic behavior. 



(a) Reo model (b) ACA 

Figure 2: Complex synchronous circuit 


The existing implementations for Reo either (i) decompose a circuit to synchronous regions and 
deploy all nodes and channels from such a region on a single machine |[T^ . (ii) propagate technical 
messages to establish which nodes are ready to process data as if there were no delays ETIl . The first 
approach is not a fully distributed solution: if the whole network consists of a single synchronous region, 
the coordination is performed by a single machine. The second approach implies no constraints on 
node deployment but it is not efficient for two reasons. Firstly, after an internal node receives a request 
message, it propagates it to the rest of the network. Meanwhile, if another message comes to the same 
node, it needs to be propagated again. Thus, internal nodes update their routing tables several times per 
execution cycle. Secondly, on each execution cycle, one node is elected to resolve non-deterministic 
choice and need to keep a list of enabled nodes for the whole synchronous region. 

Consider a circuit with a merge fragment in Figurej^ Assuming that both input ports A and B receive 
write requests simultaneously, in the time-agnostic implementation 1(211 . the merge node C propagates 
the request that arrives first. I.e., if ti < t 2 , the merge node assumes that only transition {A,C} is enabled. 
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{A,CmC} 


{bA,bC} {bB,bC} 



{uA,uC} {uB,uC} 


(a) Circuit 


(b) CA (c) ACA with port blocking actions 


Figure 3: Merge circuit and its semantics 


In time t 2 —1\ it learns that {B,C} is enabled as well and sends a new technical message to notify other 
nodes in the synchronous region. This causes undesired traffic and does not scale well. Furthermore, 
the non-deterministic choice introduced by C is not resolved locally, but delegated to an external node 
(elected randomly, depending on its ID). Thus, the existing implementation is not optimal in time-aware 
environment and relies on centralized resolution of non-determinism at each execution cycle to ensure 
absence of inconsistencies. 

We need a time-aware sematic model for Reo that displays their internal state changes (e.g., from idle 
to waiting for reply to committed and back to idle). TCA [2] models circuit time delays while ACA ifT^ 
allows multiple actions to be observed on node and channel ports. We combine these two models to 
describe our handshaking protocol. 

Let be a finite set of clocks and v : ^ M>o be a clock assignment function as defined in f2l|- 
Let also cc be a clock constraint for C, which is defined as a conjunction of atoms of the form xQn 
where ©£{<,<,>,>,=} and n gN. CA(^) (or CA) denotes the set of all clock assignments 

and CC(f€) (or CC) the set of all clock constraints. 

Definition 4.1 (Timed ACA) A Timed ACA (TACA) is a tuple sA = {S,^,cC ,^,so,ic), where S is a 
finite set of states, ^ is a finite set of clocks, cC is a set of action names derived from a set of port names 
.JT and a set of admissible action types fT, ^CSx 1 '^ x DC x CC xS is a transition relation such 
that DC is the set of data constraints over a finite data domain Data, sqG S is an initial state, ic : S ^ CC 
is a function that assigns to any location s an invariance condition ic{s). 

Let an injective function act : .JT x ST ^ define action names for each pair of a port name and 
an action type observed on the port as discussed in lIT^ . The action synchronization function y : o/L —)• 
jV\ X jCi is defined through a pair of injective functions y \: .yV -y JV\, 72 : .yV -y .jCi from a new set of 
action names JV into .yV\ and .yV). iflSl . 

Definition 4.2 (Product of TACA) For two TACA ^2/1 = (^i, , .Aj, —)> 1, ig, /ci) and £^2 = {S2,^2,Cl2, —^2 

, 5q, /C2) and the action synchronization function 7: yC -y yV) x JV2 with y\ : yV -y JV\ and 72 : JC -y M2, 
the TACA ixiy called the y-synchronization product of sA\ and y/2, A given by sA\ My SA2 = 
(Si X S2,'^1 U'iC2,Mj'|yM^',->,(5^,5^),/c((5i,52))) where ic{{s\,S2)) = xiic{si)) Axiic{s2)), for any 
i'l G Si ,52 £ S2, X ■ CCi UCC2 —)• CC is a clock constraint and location invariance condition update 
function, and the transition relation -y is determined by the following rules: 

NugUCCl N2,g2,CC2 

5l -)-i ti Ni c Mj' S2 ->-1 t2 N 2 C ypf 

Ni,gcX{rci) N2,g2.X{rc2) 

{s\,S 2 ) - {hAi) {siAi) -^ {sidi) 

and 

Ni,guCCi N2,g2,CC2 

->1 ti S2 - t2 7i (M) = 72 (-^ 2 ) 

MI r^ 2 , rigi Ag 2 ), r(z (cci) Az (cc 2 )) 

(‘S'l,i' 2 ) -^ {hdi) 


( 2 ) 
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Function x is introduced to update invariance conditions and clock constraints in composed circuits. 
In particular, this extension is needed to increase timeouts for composed networks. For example, if 
invariance conditions in are in the form x <Ti and the invariance conditions in are in the form 
< ^2, by setting x{^ ^ = x < Ti + T2, and x{^ ^ T2) = x < Ti + T2, we extend timeout needed for 

the traversal of the composed network. Consequently, clock constraints in the form x>Ti and x > r2 are 
replaced with x> T1+T2. 

We define the hiding operator h.i.de{r^,K), where A' is a non-empty set of actions K C and a 
state-transition graph of TACA analogously to the TCA |f2i]. The only distinction is that instead of 
the nodes set as in CA we deal with the action sets as in ACA. 

To reason about time-agnostic Reo semantics, we need to abstract from time in TACA. We omit data 
constraints and focus on action synchronization constraints. Let q = {s,v) be a state of a state-transition 
graph of TACA G^. We call a finite or infinite sequence of transitions 

Nifi W2/3 

r = q -^ qi - q2 -^ ^3 ••• 

a q-trace in G^. We say that a finite or infinite sequence of transitions 

No Ni N2 

r = q -^ qi - q2 -^ ^3 ••• 

is an untimed q-trace iff there exist to,ti,t2,... G M> such that 

No,to Ni,ti N2,t2 

r = q -> qi -> q 2 -> <?3 

is a ^-trace in 

Let Q* be the set of all finite sequences over a set 2 = {(5, v) 1 5 G S}. Given finite sequences 
ai and 02, we denote their concatenation ai • 02- If for some TACA there exists an untimed trace 

JVi{}{}A^2{}W3{} 

q -)• p, where Ai, A2,A^3 G are sets of actions representing TACA labels, we write 

Ni-N2-N3 

q ^p- 

5 Reo handshaking protocol 

I/O requests arrive to the Reo source nodes from writers, or to the sink nodes from readers. Writers 
and readers for synchronous regions are either external components or buffered Reo channels. Once a 
pending request is detected, the boundary node initiates handshaking message exchange through channels 
that connect it with its neighbors, reporting its status and requesting to confirm the ability to accept 
or provide data. At this stage, channels work as simple communication links between adjacent nodes 
regardless of their semantics. 

Three message propagation strategies are possible: (i) forward propagation, when the handshaking is 
initiated by writers, readers remain passive and reply to the arrived messages; (ii) backward propagation, 
when the communication is initiated by readers, writers are passive; and (iii) two-side propagation, 
when both writers and readers can initiate the message exchange. Two-side propagation minimizes 
handshaking delay, but it is also more difficult to implement. In the remainder of this paper we consider 
forward propagation. 

The handshaking behavior of Reo nodes depend on their type (input, output, simple internal, merge, 
replicate, route, or join) and (the number of) adjacent channels. Nodes can exchange three types of mes¬ 
sages: (i) intention to write {write), (ii) possibility to read (read), and (iii) possibility to write {mayrwrite). 
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Figure 4 : Handshaking behavior of source, sink, and simple mixed nodes 

The third message type is needed for routers to obtain status of nodes in alternative branches without giv¬ 
ing definite promise to write data. Together with three message types, four actions are recognized at each 
channel port: (i) send a message to an adjacent node, (ii) receive a message from an adjacent node, (iii) 
block (or commit) port, (iv) unblock the port. 

Figurej^shows the TACA for simple Reo nodes: a source node with one output port Aoh?, a sink node 
with one input port A;„, and a mixed node with one input port and one output port Agut- We use a set 
of action types = {?,!} x {w,r,mw} to represent sending and receiving of write, read, and mayjwrite 
messages, respectively. We also use a set of actions = {b,u} to define blocking and unblocking 
of node ports. Thus, a sef of action names derived from fhe sef of port names {A,„,Ao„,} and a sef of 
admissible action fypes ^ U is ^ U ^out where 

Aiin = {?>vA,-„, \wAin,lrAi„, \rAin,lmwAi„, \mwAin,bAin,uAin} 

is a sef of acfions observed on fhe node’s inpuf porf, and 

tXloijf = \lwAouti ^-wAout■,‘irAoui 1 ^-rAgut,lmwAoiit, \mwAoutibAgutlUAgut^ 

is fhe sef of acfions observed on ifs oufpuf porf. If a node performs fhe same acfion on all ifs porfs 
simulfaneously, we wrife aA \a^ ^. For example, M and mA sfand for “block/unblock all porfs of node 
A”, respecfively. 

The handshaking behavior of a source node is shown in Figure | 4 (a)[ ). The source node A sends a 
write message fhrough ifs oufpuf porf and waifs for a reply for fhe time x where T is a fimeouf large 
enough fo guaranfee fhaf any message in fhe synchronous region of fhe circuif is propagafed fo fhe mosf 
remofe (in terms of fhe communication delay) node and back. If fhe node does nol receive a reply from 
fhe accepting parly, if assumes lhal fhe laller is nol ready fo read and discards fhe requesl. If fhe answer 
is received (i.e., \rAout), the node commils fo Iransfer dala by blocking ifs porfs (M). Finally, after fhe 
fimeouf expires, fhe node unblocks ifs porfs {uA) and relums fo fhe inilial sfale. 

The sink node (see Figure | 4 (b)| ) is a passive node lhal waifs for fhe write or mayjwrite messages. 
After such a message is received, if eilher confirms ifs readiness fo accepl OrAjn) or ignores fhe message 
and relurns fo fhe inilial sfale. The Iransifion shown wilh fhe dashed line is nol required for always 
accepfing sink nodes. If fhe write message is received and fhe node is ready fo accepl, if goes fo fhe 
commilfed sfale. If fhe mayjwrite was received and fhe node confirmed fhe infenlion fo accepl, if awaifs 
for fhe confirmalion fo wrife (!wA;„), replies fo if and only Ihen commils. 

The mixed node exhibils fhe behavior which is fhe combinalion of fhe above. If accepl fhe incoming 
messages and forwards fhe fhem fo ifs neighbor fhough fhe oufpuf porf (?wAo„, and ImwAgut), wails for 
fhe reply {\rAout) and forwards if back fhrough fhe inpuf porf {lrAi„). Similarly, if !wA,„ is received affer 
\mwAin, fhe mixed node forwards fhe write requesl fo fhe oufpuf porf, wails for fhe acknowledgemenl, 
forwards if fo fhe sender, and commils. 
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Note that it is important to acknowledge both mayrwrite and write messages to be able to propagate 
I/O information in the circuit: the read message in response to a may .write message is just a confirmation 
that some accepting sink node exists in the circuit, yet the data transfer through a particular node may 
not happen due to the non-deterministic choices of internal Reo nodes. In contrast, the read message in 
response to a write message means that the exchanging parties agreed to transfer data. 

Considering the presence of may.write messages followed by write messages, T can be roughly 
estimated as C times the longest path in the (synchronous region of the) Reo circuit graph, where C is a 
constant that depends on the number of branches for merge nodes that may receive may.write messages. 
We will address the issue of computing the lower bound on timeout delays in our future work. 

The handshaking behavior of the replicate node with input port and output ports Aouti and Aouti is 
shown in FigureOnce a write or may.write message is received, the node sends a may.write message 
to its both output ports and waits for the replies. If meanwhile the timeout expires, the node returns to its 
initial state. If both neighbors confirm fheir abilify fo read, fhe furfher processing depends on fhe sfafus of 
fhe inpuf porf: if fhe write message was received initially, fhe node A knows fhaf if is able fo provide dafa 
fo ifs oufpuf porfs and fhus sends {'iwAout\,'iwAouti] to agree on fhe cerfain dafa exchange wifh fhem. 
If bofh \rAout\ and IrAouti are observed, A forwards fhe reply back fhrough ifs inpuf porf and commifs 
{bAin). Alfemafively, if \mwAi„ inifially friggered fhe decision making cycle on A, if has fo requesf for 
the confirmation of the flow (?rA,„), and if it is confirmed (!wA,>i), proceed as before. The difference in 
fhe procedure for fhe friggering may.write message is shown wifh dashed lines. 

The behavior of fhe merge node wifh fwo inpuf porfs A,>,i and A,„2 and one oufpuf porf Agut depends 
on fhe fype of fhe incoming messages: bofh write, bofh may.write, or fhe combinafion of write and 
may.write. In fhe firsf case (see Figure |6(a)[ ), fhe merge node in ifs inifial sfafe waifs for an incoming 
message on af leasf one of ifs inpuf porfs, !wA,>,i, !wA,„2 or bofh, forwards fhe incoming write message 
fo fhe oufpuf porf {IwAout), and waifs for fhe confirmation fo read (IrAout)- If one inpuf message is 
received, fhe node waifs for fhe incoming message on fhe ofher inpuf porf. If fhe second message does 
nof arrive wifhin fhe fimeouf, if means fhaf fhe ofher wrifer is nof ready fo wrife and A will proceed wifh 
the available request. If both input ports received a write request, the merge node chooses an incoming 
port to accept data from. Once the decision is made, the node A sends the read message to the selected 
input port (?rA,>,i or ?rA,>,2) and commits ({M,„i,Mo„J or {bAi„2,bAout})- 
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(a) Merge node with both source ends ready to write 



(b) Merge node with both source ends that may write 

Figure 6: Merge node 


In Figure 6(b) !mwA,„i and \mwAi„2 are initially received. This means that the sender tries to es¬ 
tablish which transactions are enabled. Consequently, after propagating the initial may-write message to 
the output port (ImwAgut) and receiving \rAout, the node A needs to wait for the definitive confirmation 
to provide data from at least one of its input ends, !wA,„i or !wA,>,2- If such a message arrives, the node 
commits, otherwise, returns to the initial state. In the case when both input nodes are ready to write, 
A non-deterministically chooses one of the branches and sends the read message to it, either ?rA,>,i or 
'irAi„2- If the selected input port receives the confirmation to write, the node forwards it to the output port 
and commits. However, the node that issued the initial may-write message may choose to fire a different 
transaction and the node A will not receive a write message. This should not exclude the transaction 
that involves the pending request on its second input port. Thus, on the timeout the node A sends the 
read message to the remaining source port. If the write message is finally received (?wAo«/), the node 
forwards it to its output port and processes further messages as in Figure |6(a) Otherwise, due to the 
external choices, the node does not participate in the data transfer at this cycle and returns to its initial 
state. The combination of write and may-write messages yield an automaton with the behavioral patterns 
shown in the above two cases. 


The route node with one input port A;„ and two output ports Aouti and Aouti receives a write message 
!>vA,„ or a may-write message \mwAin, forwards it to its output ports and waits for the read messages. 
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Figure 7 : Route node 

Figure]^ shows the case for the initial write message, the mayjwrite is processed in a similar way and is 
omitted due to the lack of space. After at least one of the output ports confirms the ability to read Q.rAouti 
and/or IrAouti), the node A non-deterministically chooses among the available options and confirms the 
intention to write (?wAoirti or IwAouti)- If the confirmation is received, the node proceeds by sending to 
the input port ?M,„ and commits or {M,>,,Moufi}). Alternatively, on the expiration of 

the timeout, the route node tries to confirm the intention to write to another enabled output port if such 
an option is available. 

For the initial mayrwrite message the mechanism is similar, but before the node decides to issue a 
definite write message, it needs to confirm the ability to read !rA,>,, receive the definite write message 
IwAin, make a choice between IwAouti and IwAouti, make sure that the port it had chosen acknowledged 
the ability to read (or try other options alternatively), send another confirmation to read to its input port 
Q.rAin) and commit. 

For the join node A to commit, both its input ports A,„i and A,„2 should receive write (or mayjwrite 
with the consequent confirmation to write) messages, and its sink port should be able to read. If only 
one input request is received within the timeout, it is discarded. If both messages are write messages, the 
node A simply checks whether the sink end can read (IwAout followed by \rAout), confirms the possibility 
of the flow to both senders ({!rA,„i, !rA,>,2}) and commits. 

Figure shows a less obvious case with one may-write input message {\mwAi„i) and one write 
message (!wA,„2)- The join node cannot guarantee the flow to its sink and thus senses whether the sink 
end can read with an uncertain may-write request {ImwAout)- If ^-rAout follows, the node should first 
request the uncertain input port to confirm the intention to write (?rA,„i). If so, the node behaves as in 
the previous case: it sends the write messages to its sink end, waits for the confirmation, forwards the 
confirmation to both input ports ({?rA,„i, ?rA,>,2}) and commits. 

Data flow in a Reo circuit is controlled not only by its nodes, but also by its channels that may per¬ 
form operations on the data they receive. What is a channel and how do we implement them? Essentially, 
each channel is an abstraction for a set of hops in a computer network to and from a component that im¬ 
plements the channel’s behavioral logic; its source port is known to data suppliers while its sink port is 
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(a) Sync (b) LossySync 

Figure 9 : Handshaking behavior of Sync and LossySync channels 


known to data consumers. From the viewpoint of handshaking protocol, Reo channels are communica¬ 
tion links to exchange messages between adjacent nodes (e.g., Sync channel). However, channels behave 
also like nodes that determine which transitions are enabled (e.g., SyncDrain and AsyncDrain). 

The handshaking behavior of a Sync channel c with communication delay t, source port C,„ and sink 
port Cout can be modeled as shown in Figure [ 9 (aj| It accepts a write or a may.write message on its source 
end {\aCin where a G {m,mw]) and notifies its sync end (laCout)- Similarly, it accepts a read message 
on its sink end Q.rCout) and transfers it to its source end {IrCm). 

The behavior of the LossySync channel as a transition link is analogous. However, its ability to 
lose data either when its output node is not ready to accept (context-dependent LossySync) or non- 
deterministically (context-independent LossySync) should be modeled explicitly. In the first case, the 
decision to accept data on the source end of the LossySync channel despite the fact that its sink end is 
unable to read can be modeled as shown in Figure [ 9 (bj| This figure shows fhe handshaking behavior of 
an always accepfing mixed node fhaf commifs fo a fransacfion fhaf involves only ifs inpuf porf affer fhe 
fimeouf of wailing for a read message from ifs oufpuf porf expires. Thus, a confexl-dependenl LossySync 
channel can be represenfed as a Sync channel join! fo such a node. 

The conlexl-independenf LossySync behaves similarly, bul if may accepl dala wilhoul nolifying ifs 
sink port, as shown by Iwo dashed Iransilions ?M,>, in Figure [ 9 (bj| in righl and lefl branches. 

Allernafively, a non-deferminislic LossySync can be modeled wilh fhe help of a rouler node fhaf eifher 
chooses fo pass dafa or reroule if fo an unobservable always accepting oufpuf node T (hash bin) where 
Ihis dala item is deslroyed. In fhe same fashion, fhe behavior of SyncDrain and AsyncDrain channels can 
be modeled wilh fhe help of auxiliary join and merge nodes as shown in Figure [T0| 





































14 


Handshaking Protocol for Distributed Implementation ofReo 



.. -- ^ 

p B SyncDrain p B AsyncDrain 

(a) SyncDrain (b) SyncDrain (c) AsyncDrain (d) AsyncDrain 

Figure 10 : Modeling handshaking behavior of SyncDrain and AsyncDrain channels 

6 Handshaking protocol correctness 

In this section, we outline the sketch of a proof that the presented handshaking TACA provides correct 
implementation for Reo. To be able to show this formally, we need to define the notion of correct 
implementation. 

Definition 6.1 (Observable trace) For a synchronous Reo circuit with a set of nodes let sF = 

jV = X be its handshaking TACA with port blocking, unblocking and 

Nl-NT...-Nn 

auxiliary actions, {b, n} C Vfe say that s > s' is an observable trace in sA if it is an 

untimed trace in hide{s^where ^ = {b,u}. 

Definition 6.2 (Correct implementation) For a synchronous Reo circuit with a set of nodes 0^, let 
SS = I ^ = 0^ X FAgg, 0Ags = {b,u} be its ACA, and sF = >'^,5o,rc) | JF = 

X 0A^ where 0A^ n = {b, u} be its handshaking TACA. The Reo handshaking protocol defined by 

s0 is a correct implementation ofReo iff there exists a mapping & : S such that 

M N{-N2' ■■•'Nfi 

• for any q -)• q' in there exists an observable trace s > s' in sF such that M = 

AiUA2U...UA„, 

N\-N2'■■■■Nfj M 

• for any observable trace s > s' in sF, there exists q - q' in M, M = Ai U A 2 U 

Intuitively, this definition requires the handshaking protocol to block and unblock only those sets 
of ports that appear in synchronization constraints of port blocking ACA. Since auxiliary actions may 
be required in the implementation, blocking and unblocking of all involved ports does not need to be 
simultaneous, it is sufficient that for each ACA transition to have a state in TACA with all necessary 
ports blocked and later unblock these ports. 

To show the correctness of our protocol, we should (i) show that TACA provide correct implemen¬ 
tation of port blocking ACA for each basic Reo node and channel as defined in |[T6l . (ii) using producf 
operator, define TACA for a composed circuif by synchronizing message exchange acfions on shared 
porfs and show thaf such a TACA is a correcf implemenfafion for fhe composed circuif. 

For each Reo node and channel, we hide all handshaking messages in fhe fime-absfracled version 
of TACA and show fhaf fhe obfained aufomafon is weakly bisimilar fo fhe porf-blocking ACA for fhis 
node or channel (or equivalenfly, fhe inifial TACA is fhe acfion refinement of the port blocking ACA). 
Compositionality of this relation helps to extend the proof to any Reo circuit. For a circuit with a set of 
nodes its handshaking behavior is given by 

sF = >-^,50,^), jY = 0F X FAsi, FA^r = {b,u0w, \w0mw, \mw0r, !r}. 

It can be checked that for all basic Reo channels and nodes, ^ rF with a set of hidden actions K = 

M 

{a X, a G -FA^ \ FAgg,X G and an empty set of renamings R = 0. Since for each q - q' in FF 

there exists s =A s' in hide{£/,X^\ ./#), .sX is a correct implementation of FS. 
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To compose the TACA for handshaking, let us define a synchronization function 7 : (71,72), 7i : 
yk' jVi , 72 : jV —)■ as follows. For any two joint ports Aout and in a Reo circuit, 


7i 

7i(??mvAo„,B,„) =lmwAout, 
7i (! rAgiit fBifi ) —! rAgiif , 
7i {bAgniBifi) — bAgiit, 

'Yi{uAgmBjfi^ — uAgufj 


Yii^wAgufBjfi) — IwBjfi, 

Yii'^mwAoutBin) =\mwBi, 

YiibAgntBifi) — bBjfi^ 
Yli^^out^in) — uBjfi. 


( 3 ) 


The definition of the implementation correctness of the handshaking protocol in the form of TACA 
is a weaker requirement than the action refinement and our synchronizing function enables an automaton 
for only one instance of suitable implementations. The TACA product without synchronizing blocking 
and unblocking actions in lines 4 and 5 of Q will also yield a correct implementation for the cor¬ 
responding port blocking ACA, but not the action refinement. It also generates a significantly larger 
automaton that is harder to deal with formally. However, in the distributed environment with commu¬ 
nication delays it may be difficult to perform simultaneous port blocking and unblocking on remote 
nodes to signal that they are ready to transfer data. In practice, we are only interested in the existence 
of a state in which all ports involved into a firing fransifion are blocked. In fhe TACA producf wifh- 
ouf synchronizing blocking and unblocking acfions, Reo porfs fhaf are ready for firing fransifions are 
blocked in any order. For example, in fhe case of a node wifh fwo porfs, bAgut and bBin, fheir inferleav- 
ing bAgut\\bBin = bAgut-bBin + bBin-bAgut + bAgut\bBin gives us fraces wifh fhe same sef {bAgut,bBi„} of 
performed acfions, which conforms fo our definition of fhe correcf implemenfafion. 


7 Related work 

Proen9a ef al. ll^ identifies five implemenfafion approaches for Reo and offers fheir own framework, 
called Dreams. The mosf sfraighfforward approach is a speculative approach: dafa is senf fhrough fhe 
channels and rolled back when an inconsisfency arises. This approach has never been implemenfed. 
The automata-based approach |[T 9 ]| relies on CA semanfics and pre-compufed behavior al compile time. 
Implementations based on connector coloring ifT^ compute all solutions for the behavior of each round 
and keep them in a routing table. Existing search-based implementations rely on structural operational 
semantics and are implemented in Alloy lITSi and Maude 1201 . The constraint-based approach |[8l applies 
SAT solving techniques to search for single solutions on each round. 

Dreams l 2 ll is the first working implementation of a distributed engine for Reo. It is based on a 
commit and send message exchange and has common traits with our protocol. However, our protocol is 
a form of a speculative approach that does not require rollbacks and unnecessary data propagation. We 
provide a theoretical model for distributed Reo implementation with desired characteristics 12 T 1 : 

• Decoupling-, each node can be deployed on a separate machine, transitions in synchronous re¬ 
gions fire independently, and handshaking message exchange occurs within the boundaries of syn¬ 
chronous regions. 

• Scalability-, similarly to the Dreams, no global consensus is required. The behavior is computed 
per step, avoiding not only the state space explosion typical for the centralized implementation, but 
also the need for each node to remember the states of other nodes in the same synchronous region. 
In contrast to the Dreams, our implementation resolves non-determinism locally by each node or 
channel with inherent non-deterministic behavior. This is a more scalable approach because it does 
not use routing tables, the decision which transition to fire is taken in the distributed manner. 
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• Reconfiguration-, runtime reconfiguration of a connector will not require any global or regional 
changes. Once a node detects a change in its environment, it only needs to adjust its own be¬ 
havior. For example, if a new channel is connected to an input port of a simple node, this node 
becomes a merge node and should behave accordingly. Formal protocol adjustment rules to enable 
reconfiguration will be developed in our future work. 

• Fault tolerance: with the exception of failures of committed nodes, our protocol is fault tolerant. 
The timeouts as opposed to the permanent locks in Dreams guarantee that a failure is treated as 
inability of a node to process data. Even in the case of a committed node failure, only current trans¬ 
action is affected, at the next step (after timeout expires on each committed state) the remaining 
circuit resumes its normal operation. 

In some applications of Reo such as coordination of processes in a multi-core execution environment, 
delays are negligible. Arriving requests are propagated through the network instantly and can be mod¬ 
eled using action synchronization. In ifTOl . a Reo-to-C compiler which generates partially-distributed 
implementations for shared-memory platforms is presented. An optimization technique to improve the 
scalability of the generated code is later introduced ifTTIl . In || 9 l and ifldl . the formal details of an imple¬ 
mentation with partial-distribution based on synchronous regions are developed. An early Reo-to-Java 
compiler, which generates completely centralized implementations is described in llT3l and used for ser¬ 
vice orchestration in ifT^ . 

The approach proposed in this paper can be used as foundation for distributed implementation of 
other coordination approaches for agent- and component-based systems where global consensus of syn¬ 
chronous entities is required. As opposed to commits and rollbacks typically employed to implement 
transactional processes f 7 l|^ sensing messages like our mayrwrite messages can be employed to elicit the 
states of remote entities before taking decisions locally. 


8 Conclusions and Future Work 

In this paper, we proposed a theoretical model for distributed implementation of Reo. We extended the 
definition of ACA with the notion of time, used this model to define what a correct implementation for 
Reo is, and described a handshaking protocol that complies with our definition of correct implementation. 
Our approach exhibits properties implied by Reo but not enforced in the previous implementations: the 
resolution of non-deterministic choices does not require centralized decisions, and the timeout mecha¬ 
nism ensures that the network does not lock due to a failure of a remote node or a channel. Consequently, 
this execution model is more suitable for real-time monitoring, QoS estimation, failure detection and re¬ 
configuration. 

Due to the space limitations we could not discuss some relevant aspects of the approach, most no¬ 
tably, computation of timeouts. We plan to extend the protocol to handle data constraints and implement 
a service that deploys and executes Reo circuits based on the presented model. The approach used in 
this paper can be applied to describe handshaking behavior of Reo nodes and channels assuming other 
propagation strategies: backward and two-side propagation. 
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